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ABSTRACT 



A method and apparatus is disclosed for providing a 
secure wireless communication link between a mobile 
nomadic device and a base computing unit A mobile 
sends a host certificate (Cert.^obile) to the base along 
with a randomly chosen challenge value (CHI) and a 
list of supported shared key algorithms ("SKCS"). The 
base determines if the Cert—Mobile is valid. If the Cer- 
t^Mobile is not valid, then the base unit rejects the 
connection attempt. The base then sends a Cert-JBase, 
random number (RNl) encrypted in mobile's public key 
and an identifier for the chosen SKCS to the mobile. 
The base saves the RNl value and adds the CHI value 
and the chosen SKCS to messages sent to the base. The 
mobile unit then validates the Cert-JBase, and if the 
certificate is valid, the mobile verifies under the public 
key of the base (Pub_Base) the signature on the mes- 
sage. The signature is verified by taking the base mes- 
sage and appending it to CHI and the list of shared key 
algorithms that the mobile provided in the first message. 
If the base signature is not valid, then the communica- 
tion attempt is aborted. In the event that the base signa- 
ture is valid, the mobile determines the value of RNl by 
decrypting Pub— Mobile, RNl under the private key of 
the mobile. The mobile then generates RN2 and the 
session key, and encrypts RN2 under the Pub— Base. 
The mobile sends the encrypted RN2 and E(Pub_Mo- 
bile, RNl) to the base. The base then verifies the mobile 
signature using the Pub—Mobile obtained from the Cer- 
tlMobile. If Uie mobile signature is verified, the base 
decrypts E(Pub_JBase, RN2) using its private key. The 
base tiien determines the session key. The mobile and 
base may then enter a data transfer phase using en- 
crypted data which is decrypted using the session key 
which is RNl eRN2. 
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' mines the value of RNl by decrypting E(Puh— Mobfle, 
METHOD ASD APPARATUS FOR PRIVACY AND RNl) under the private key of the mobile. The mobile 
AUTHENTICATION IN WIRELESS NETWORKS then generates RN2 and the session key (RNIO RN2), 

and encrypts RN2 under the Pub—Base, The mobile 
BACKGROUND OF THE INVENTION 5 sends the encrypted RN2 and E(Puh-Jdobile. RNl) to 

1. Field of the Invention the base in a message signed with mobile's private key. 
The present invention relates to methods and appara- Th® verifies the mobile signature using the 

tus for providing privacy and authentication in a wire- Pub— Mobile obtained from the C£RT_Mobile. If the 

less network. More particularly, the present invention mobile signature is verifiedi the base decrypts £(Pub 

provides a system using both public key and shared key Base, RN2) using its private key. The base then deter- 
encryption techniques for communications between mines the session key (RN1®RN2). The mobile and 
wireless mobile devices and a base station. base may then enter a data transfer phase using en- 

2. Art Backgroimd crypted data which is decrypted using the session key. 
The advent of portable personal computers and The present invention further provides a method for 

workstations has expanded the concept of networks to changing the session key during a session, and the abU- 
include mobile devices. These mobile devices may be ity to use multiple certificates of authentication (CA) in 
moved between global networks as well as within local the case of large networks, 
networks. For example, a user of a portable notebook 

computing device may physically carry his computer BRIEF DESCRIPTION OF THE DRAWINGS 
from Palo Alto, California to Bangkok, Thailand. If the 20 pjQ | illustrates a data processing system mcorpo- 
computer must interact and communicate with other rating the teachings of the present invention, 
computers coupled to a network, issues of network piG. 2 diagrammaticaUy illustrates the difference 
security naturally arise. In particular, if the user's com- between link security and end to end security in a multi- 
puter conimmucates over a wireless link, for example network system incorporating the use of mobile 

with a local base station or through a direct satellite hnk 25 

from Bangkok to the United States, wireless security, 3 diagrammatically iUustrates a mobile user 

privacy and authraUcation becomes miportant The communicatine with several users coupled to multiple 
wireless medium mtroduces new opportumties for al- networks. *- *- 

lowing eavesdropping of wireless data communications. pj^g Aa. 4b and 4c conceptually illustrate the se- 
Anyone with the appropriate type of wireless receiver 30 * ^^'^^ ""^ ""^ wuK^y^uauy muauaic uic 

J ff, . , . , i*^ , . Quence of steps executed by the mobile and base to 

may eavesdrop, and this kmd of eavesdroppmg IS virtu- ^ rZTxT ^^^^^ ^ , .T^^u * 

aUy undetectable. Furthermore, since the ^^^eless me- * ^ accordance with the teachmgs 

dium cannot be contained by the usual physical con- '^^^tl^''^ '^''fP.^J?'^- „ ^ 

straints of walls and doors, active intrusioi^ through the f f 5/r jjl^^t^te a flowchart of the steps 

wireless medium are also easier to accomplish. 35 executed by the mobile and base conceptually shown m 

As will be described, the present invention provides a FIGS. 4a-4c 
method and apparatus for preventing the opportunity NOTATION AND NOMENCLATURE 

for unauthorized access to the network, and a secure ^ 

communication protocol that provides for both privacy ^h® detailed descriptions which follow are presented 
of the wireless data communications, as well as authen- 40 largely in terms of symbolic representations of opera- 
ticity of the communicating parties. of data processing devices coupled to a network. 

These process descriptions and representations are the 
SUMMARY OF THE INVENTION means used by those skilled in the data processing arts 

The present invention provides method and appara- "lOst effectively convey the substance of their work 
tus for providing a secure communication link between 45 to others skilled in the art 

a mobile wireless data processing device and a base ^ algorithm is here, and generally, conceived to be 
(fixed node) data processing device which is coupled to ^ self-consistent sequence of steps leading to a desired 
a network. The mobile sends a host certificate (CER- result. These steps arc those requiring physical manipu- 
T_Mobile) to the base along with a randomly chosen lations of phyacal quantities. Usually, though not; nec- 
challenge value (CHI) and a list of supported shared 50 essarily, these quantities may take the form of electrical 
key algorithms ("SKCS"). The base verifies the certifi- or magnetic sigiials capable of being stored, transferred, 
cate which is digitally signed by a trusted certification combined, compared, displayed and otherwise manipu- 
authority(CA). If the CERT— MobOe is not valid, then lated. It proves convenient at times, principally for 
the base unit rejects the connection, attempt The base reasons of common usage, to refer to these signals as 
then sends a CERT—BASE, random number (RNl) 55 bits, values, elements, symbols, operations, messages, 
and an identifier for the chosen SKCS to the mobile. terms, numbers, or the like. It shoiUd be borne in mind. 
The base saves the RNl value and adds the CHI value however, that all of these similar terms are to be assod- 
and the chosen SKCS to messages sent to the base by ated with the appropriate physical quantities and are 
the mobile. The base then signs this message and sends merely convenient labels applied to these quantities, 
it to the mobile. The mobile unit then validates the 60 In the present invention, the operations referred to 
CERT—BASE, and if the certificate is valid, the mobile are machine operations. Useful machines for perform- 
verifies under the public key of the base (Pub— BASE) ing the operations of the present mvention include gen- 
the signature on the message. The signature is verified eral purpose digital computers, or other similar devices, 
by taking the base message and appending it to CHI and In all cases, the reader is advised to keep in imnd the 
the list of shared key algorithms (SKCS) that the mobile 65 distinction between the method operations of operating 
provided in the fu^ message. If the base signature is not a computer and the method of computation itself. The 
valid, then the communication attempt is aborted. In the present invention relates to method steps for operating 
event that the base signature is valid, the mobile deter- a computer, coupled to a series of networks, and pro- 
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cessing electrical or other physical signals to generate 
other desired physical signals. 

The present invention also relates to apparatus for 
performing these operations. This apparatus may be 
specially constructed for the required purposes or it 5 
may comprise a general purpose computer selectively 
activated or reconfigured by a computer program 
stored in the computer. The method/process steps pres- 
ented herein are not inherently related to any particular 
computer or other apparatus. Various gen^^ purpose 10 
machines may be used with programs in accordance 
with the teachings herein, or it may prove more conve- 
nient to construct specialized apparatus to perform the 
required method steps. The required structure for a 
variety of these machines will be apparent from the 15 
description given below. 

DETAILED DESCRIPTION OF THE 
INVENTION. 

In the following description, numerous specific de- 20 
tails are set forth such as system configurations, repre- 
sentative messages, wireless devices and base stations, 
etc., to provide a thorough understanding of the present 
invention. However, it will be apparent to one sldlled in 
the art that the present invention may be practiced 25 
without these specific details. In other instances, weU 
known circuits and structures are not described in detail 
in order to not obscure the present invention. More- 
over, certain terms such as "knows", "verifies", "exam- 
ines", "finds", "determines", "challenges", "authenti- 30 
cates", etc., are used in this Specification and are con- 
sidered to be terms of art The use of these terms, which 
to a casual reader may be considered personifications of 
computer or electronic systems, refers to the fimctions 
of the system as having human like attributes, for sim- 35 
plicity. For example, a reference herein to an electronic 
system as "determining"something is simply a short- 
hand method of describing that the electronic system 
has been progranuned or otherwise modified in accor- 
dance with the teachings herein. The reader is cau- 40 
tioned not to confuse the fimctions described with ev- 
eryday human attributes. These fimctions are machine 
fimctions in every sense. 

EXEMPLARY HARDWARE 

FIG. 1 illustrates a data processing system in accor- 
dance with the teachings of the present invention. 
Shown is a computer 1 which comprises three major 
components. The first of these is an input/output (I/O) 
circuit 2 which is used to communicate information in 50 
appropriately structured form to and firom other por- 
tions of the computer 1. In addition, computer 1 in- 
cludes a central processing (CPU) 3 coupled to the I/O 
circuit 2 and a memory 4. These elements are those 
typically found in most general purpose computers and, 55 
in fact, computer 1 is intended to be representative of a 
broad category of data processing devices. Also shown 
in FIG. 1 is a keyboard 5 to input data and conmiands 
into computer 1, as is well known. A message genera- 
tion and transmission/receiving circuit 7 is also coupled 60 
to the computer 1 through I/O circuit 2, to peimit the 
computer 1 to communicate with other data proces»ng 
devices. For example, in FIG. 1, the computer 1 is a 
nomadic device which communicates with other data 
processing devices using a wireless transmitter 8, as 65 
shown. However, it will be appreciated that the com- 
puter 1 may also be directly coupled to a network, in 
accordance with the teachings herein. A raster display 
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monitor 6 is shown coupled to the I/O circuit 2 and is 
used to display images generated by CPU 3 m accor- 
dance with the present invention. Any well known 
variety of cathode ray tube (CRT) or other type of 
display may be utilized as display 6. 

INVENTION OBJECTIVES 

The design goab of the protocol of the present inven- 
tion presented herein, and its placement in the protocol 
stack of a wireless mobile device and a base station, are 
driven by a number of requirements. A major require- 
ment is that the placement of the security fimction of 
the present invention in the protocol stack be a seamless 
integration into existing wired networks. A very large 
number of network applications operate in the existing 
wired network world. The applications typically as- 
sume some level of security in the network. This secu- 
rity is, in some sense, provided by the physical security 
of wired networks. Unfortunately, since a wireless me- 
dium has no physical protection, introducing a wireless 
network negates any inherent protection which a physi- 
cal network provides. In the interest of allowing the 
existing software application base to function at least as 
securely as it did over a wired network, the present 
invention secures the wireless link itself. 

Two other alternatives, end-to-end security at the 
application layer and end-to-end security at the trans- 
port layer, are considered inadequate, given the require- 
ment for seamless integration into the existing wired 
networks. An implication of seamless integration is that 
the very large number of existing nodes in a wired net- 
work should not be modified. Stipulating either of ap- 
plication or transport layer based end-to-end security 
would require modifying the software base of the entire 
fixed node network, should the mobile portable com- 
puting device need to have the same level of network 
access as any node on the wired network. 

For purposes of background, the difference between 
link security and end-to-end security is illustrated in 
FIG. 2. A mobile computer 10 is in wireless communi- 
cation with a base unit 12. The mobile 10 and base unit 
12 comprise a computer system such as that illustrated 
in FIG. 1. The base unit 12 is a fixed node of a network 
14. A gateway 16 is provided to permit communication 
between the network 14 and a second network 18, as 
shown Fixed node data processing devices 20 and 24 are 
coupled to the network 18. A link level security ap- 
proach requires that the wireless link between the mo- 
bile 10 and base 12 be secure. Existing security mecha- 
nisms for networks 14 and 18, as well as the gateway 16 
need not be affected by the addition of the secure wire- 
less link. In an end to end security mechanism, the mo- 
bile 10 communicates directly with a fixed node (for 
example, fixed node 20), thereby requiring that all of the 
software for each fixed and mobile node in networks 14 
and 18 be upgraded to be compatible and achieve the 
same level of network security. 

In an operational environment where it is considered 
feasible to upgrade all nodes in the network to be com- 
patible with end-to-end security mechanisms, link secu- 
rity may in fact not be necessary. This is clearly not 
possible in very large corporate networks, or large 
multi-organizational networks like the Internet. The 
link-level security approach adopted in the design illus- 
trated in FIG. 2 obviates the need for upgrading the 
software in the existing wired network. The wireless 
link itself is secured, and thus the security of the overall 
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network, wired plus wireless, is no less than the security 
of the wired network alone. 

It will be apprecdated that the link level security ap- 
proach does not rule out end-to^d security mecha- 
nisms. Such mechanisms can coexist with link-level 5 
security, by running an additional secure protocol on 
top of the link protocol Security at multiple locations in 
the protocol stack is not necessarily considered harmful. 
The approach shown in FIG. 2 does not put the burden 
of providing end-to-end security at the time the wireless 10 
networks are deployed, but rather when it makes eco- 
nomical sense to secure the entire network by end-to- 
end mechanisms. 

The link layer involves communication between at 
least two machines, for example between mobile 10, 15 
base 12, and fixed node 20. The concept of users at the 
link layer is not truly appropriate, since multiple users 
are typically multiplexed on a single link layer. For 
example, a mobile user may be communicating with 
several users over the wireless link at the same time. All 20 
of these "conversations" arc multiplexed on top of the 
same link layer. The link hiyer itself is only one hop of 
many, in a typical wireless plus wired network. (TJus 
situation is illustrated in FIG. 3). As shown in FIG. 2, a 
mobile unit 25 is in wireless communication with a base 25 
27 coupled to a network 30. The base 27 is one of many 
fixed nodes (for example, fixed node 32) coupled to the 
network 30. A gateway device 34 coupled between the 
network 30 and a network 36 permits communication 
between nodes coupled to the respective networks. For 30 
example, a fixed node 38 coupled to network 36 may 
conununicate over the gateway 34 to fixed node 32, or 
through the base 27 to the mobile 25. 

Since end-to-end mechanisms are not stipulated, user 
authentication is thereby ruled out. What is left there- 35 
fore is node-to-node (or Tnarhinpvtft-marhmp) authenti- 
cation, since those are the entities primarily conmiuni- 
cating over the wireless link. Machine-to-machine au- 
thentication is conceptually appropriate for a security 
protocol at the link layer. 40 

Another design goal in the system of the present 
invention is that authentication includes mutual authen- 
tication. Namely, it is desirable that both ends of the 
wireless link (the mobile 25 and the base 25) to be able 
to authenticate each other. Only authorized nomadic 45 
computing devices will have access to network re- 
sources. Authenticating the base 25 is also necessary, if 
one considers the situation of competitors located in the 
same industrial park. The base stations of one competi- 
tor should not be able to masquerade as belonging to the SO 
other competitor. Mutual authentication serves this 
goal and h provided by the present invention as de- 
scribed below. 

Another goal of the invention is to have flexibility in 
terms of being able to take advantage of future advances 55 
in shared-key cryptography. There is a need to allow 
interoperability between all versions of a seciure wire- 
less product 

Overview of the Present Invention 

The present invention uses both public key (See W. 60 
Diffie and M. Hellman, "New Directions in Cryptogra- 
phy**, IEEE Transactions on Information Theory, IT- 
22:644-645, 1976) and shared key cryptographic tech- 
niques to achieve privacy and authenticity. Public key 
cryptography is used to do session key setup and au- 65 
thentication. Shared key cryptography is used to pro- 
vide privacy aspects of the protocol of the present in- 
vention. 
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Each participant node in the protocol of the present 
invention generates a public key/private key pair. The 
private key is kept securely by the owner of the key 
pair. The public key is submitted over a secure channel 
to a trusted Certification Authority (CA). The CA ex- 
amines the relevant information to ascertain that the 
public key is indeed bemg presented by someone whose 
identity is known and who can be "trusted". Having 
submitted the public key, the person submitting is as- 
sumed to be in a position to obtain credentials on behalf 
of the machine whose public key is being certified. The 
CA will then issue a certificate to the person (who is 
acting on behalf of the machine). The certificate will 
contain a binding between the public key and a logical 
identifier of the machine (such as a machine name), in 
the form of a document digitally signed using the CA's 
private key. 

Having obtained a certificate for each machine, as 
welLas secure backup of the private keys, the mobile 
and base are in a position to engage in a secure protocol. 
The two parties exchange certificates and engage in a 
mutual challenge-response protocol. The protocol al- 
lows negotiation of the shared key algorithm. This al- 
lows for enhancing the protocol in the fiiture to better 
sliared key cryptosystems and also allows for interoper- 
ability between US and non-US versions of the product, 
should they require different encryption algorithms for 
exportability purposes. 

The protocol also provides for good forward se- 
crecy. If the private components of thic public-private 
key pair of eitiier the base or the mobile should be com- 
proxiiised at some future point in time, then this compro- 
mise does not necessarily compromise the wireless hnk 
data that has been exchanged by a machine whose pri- 
vate key has been compromised. This protocol requires 
compromise of both the base and the mobile's private 
key to compromise communication between the base 
and mobile. This is considered a less likely event than 
the compromise of either one of the keys. 

In accordance with the teachings of the present in- 
vention, no assumptions are made about any of the key 
lengths, which can be lengthened or shortened for the 
environment and time frame. 

DEFINITIONS 

For purposes of this Specification, the following 
terms, negotiations and abbreviations shall have the 
following meaning: 
E(X,Y) should read as encryption of Y under key X. 
MD(X) should read as the Message Digest function 

value on contents X. 
Public Key of Certification Authority =Pub_CA 
Private Key of Certification Authority =Priv_CA - 
Public Key of Mobile Host =Pub_Mobile 
Private Key of Mobile Host =Priv_Mobile 
Public Key of Base Station =Pub— Base 
Private Key of Base Station =Priv— Base 
Certificate of Mobile Host =Cert-J4obile 
Certificate of Base Station =Cert_Base 
Sig(X,Y) should read as signature of Y with key X 

where Sig(X,Y) =E(X.MD(Y)) 
Signed(X,Y) represents the resulting signed message 

{Y, SigPCY)} 

SECURE PROTOCOL OF THE PRESENT 
INVENTION 

Referring now to FIGS. 4a-4c and the flowchart of 
FIGS. 5a and Sk at connection initiation time, a mobile 
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100, requesting to connect to a wired networit, sends its 100. The base 105 will save RNl internally for later use. 

Host Certificate (Cert-Mobile) to a base 105» a 128-bit For purposes of confuting the message signature, the 

randomly chosen challenge value (CHI) and a list of base 105 will add both the challenge value CHI and the 

supported shared key algorithms ("SKCS"). list of shared key cryptosystems to the messages that it 

The list of supported shared key algorithms is in- S sends out 

tended to allow for negotiation of shared key algo- The SKCS is chosen from the intersection of the set 

rithms (eg. FEAL-32, DES, IDEA, etc.) with the base of shared key algorithms proposed in message # 1 by the 

105. The shared key algorithm will be used to encrypt mobile 100 and the set that the base 105 supports. The 

subsequent data packets. Negotiation of shared key base 105 chooses the SKCS algorithm it deems the most 

algorithms can allow for interoperability between say, 10 secure from the intersection of the two sets. The key 

domestic and foreign versions of the privacy modules. size is always negotiated downwards to the fninimntw of 

A Certificate contains the following information: what the mobile 100 proposes and what the base 105 can 

{Serial Number, Validity Period, Machine Name, support for the chosen algorithm. 

Machine Public Key, CA name} . Message #2. Base-*Mobile 

Certificate =Signed(Priv_CA, Certificate contents) 15 {Cert-Base, E(Pub_MobUe, RNl), Chosen SKCS, 

The certificate format and encoding is chosen to be Sig(Priv_Base, {E(Pub-Mobile, RNl), Chosen 

the same as the certificate format defined in CCTTT SKCS, CHI, List of SKCSs)} 

X.509 (See CCITT Recommendation X.509 (1988), Continuing to refer to FIG. 3. the chosen SKCS 

"The Directory- Authentication Framework"), and identifies both the chosen algorithm and the associated 

Privacy Enhanced Mafl (PEM) (See S. Kent, "Privacy 20 key size. The signature that is appended to the message 

Enhancement for Internet Electronic Mail: Part II Cer- is different from the normal ^gning of a message, as it 

tificate-Based Key Management", RFC 1422, BBN, includes something that is not part of the body of the 

February 1993; B. Kaliski, "Privacy Enhancement for message, but rather something implicit in the protocol. 

Internet Hectronic Mail: Part IV: Key Certification The mobile 100 first validates the Certificate of the 

and Related Services", RFC 1424, BBN, February 25 base 105 (Cert-Base), using CA's pubUc key and the 

1993). ! This allows the mobile 100 and the base 105 digital signature verification procedure described 

station to leverage from the same certificate infrastruc- above. If the Certificate is valid, then the mobile 100 

ture required by X.500 and PEM will verify under the public key of the base 105 (Pub— 

A Message Digest (MD) function is computed on the Base) the signature on the message, 

host certificate (Cert_Mobile) contents and is digitally 30 The signature is verified by taking the base's message 

signed by a trusted Certification Authority (CA). The and appendiag to it CHI and the list of shared key 

"signing" is accomplished by encrypting the MD (a algorithms that the mobile 100 sent in the first message, 

non-invertible hash function ia the certificate contents) The inclusion of the list for the purposes of signature 

under the private key of the CA. This authenticates the verification allows message # 1 to be sent unsigned. If an 

contents of the certificate (Cert— Mobile), but does not 35 attacker wants to weaken the list of shared key algo- 

make the contents private. For details on the topic of rithms, by jamming the original message and inteiject- 

certificate based key-management and certificate issu- ing his own list, then this will be detected by the mobile 

ing, the reader is referred to RFCs 1422 and 1424 (See 100 on receipt of the second message. If the signature 

S. Kent, 'Trivacy Enhancement for Internet Electronic matches, then the base 105 is deemed to be authentic. 

Mail: Part n Certificate-Based Key Management", 40 Otherwise, the base 105 is deemed an impostor or the 

RFC 1422, BBN, February 1993; B. Kaliski, "Privacy original message is suspected of bemg tampered with 

Enhancement for Internet Electronic Mail: Part IV: and the mobile 100 will abort the connection attempt. 

Key Certification and Related Services", RFC 1424, The value RNl is obtained by the mobile by decrypt- 

BBN, February 1993) and CCITT standard X.509. ing E(Pub_Mobile, RNl) under the private key of the 

The first message from the mobile 100 to the base 105 45 Mobile 100. The Mobile 100 then generates another 

requesting to join the wired network contains the infor- random number RN2 and will use the value (RNl 0 

mation as shown below; RN2) as the session key. 

Message #1. Mobile-43 Base To complete the authentication phase and to commu- 

{Cert-Mobile, CHI, List of SKCSs} nicate the second half of the key RN2 to the base 105, 

CHI is a randomly generated 128-bit number. The list 50 the mobile 100 will encrypt under Pub— Base the value 

of shared key algorithms includes both an algorithm RN2 and send this in a message, including the original 

identifier and a key size. encrypted RNl value it obtained in message #2. The 

The base 105, upon- receipt of this request to join inclusion of E(Pub_Mobile, RNl) m the third message 

message, will attempt to validate Cert— Mobile. This is serves to authenticate the Mobile 100, because a signa- 

done by independently computing the MD on the con- 55 ture is computed on it, using the mobile's private key. 

tents of Cert-JMobile and comparing this with the de- Message #3. Mobile-«>Base 

cryption under the public key oftheCA of the "signed" {E(Pub-JBase, RN2), Sig{Priv-Mobile, {E(Pub— 

MD. If these two values match, then the certificate is a Base, RN2), E(Pub_Mobile, RNl)}}} 

valid one, although at this pomt the base 105 does not As shown in FIGS. 4a-c and Sa-Sb, the base 105 

know whether the mobile 100 also possesses the Private 60 verifies the signature of the message using Pub_Mobile 

Key (Priv_Mobile) associated with the Public Key obtained from Cert— Mobile in message #1. If the signa- 

presented in the certificate Cert-Mobile. ture verifies, then the mobile 100 is deemed an authentic 

If the certificate is invalid, the base 105 rejects the host, otherwise the mc*ile 100 is deemed an intruder 

connection attempt. If the certificate verifies, the base and the base 105 will reject the connection attempt. 

105 will reply with its Certificate, a random number 65 Prior to entering the data transfer phase, the base 105 

RNl encrypted under the public key of the mobile 100 will decrypt E(Pub— Base, RN2) using its own private 

and tiie Shared Key CryptoSystem (SKCS) that tiie key. It will also then use (RN10RN2) as the session 

base 105 chose out of the list presented by the mobile key. The reason that two random values are used for the 
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key (as opposed to simply using RNl for the key) is tive stream ciphers in the presence of undetected or 

because this limits the damage that can occur if the corrupted or out-of-order wireless link packets, 

private keys of one of the mobiles gets compromised. For DES in cipher feedback mode or counter driven . 

This approach requires the compromise of both the base mode, the **message id** is the last 64 bits of cipher text 

105 and the mobile's private keys, for preceding traffic 5 of the last packet For DES in output feedback mode, 

between that base 105 and mobile 100 to be compro- the '^message id" is simply the count of the number of 64 

'"ised. bit blocks that have been sent The length of the **mcs- 

Since both halves of the key are of equal length and sage id" field and its meaning are implicit in the choice 
completely random, knowing either one of RNl or of the shared key algorithm and its operating mode. 
RN2 tells an attacker absolutely nothing about the ses- 10 Integrity checking of data packets is done by trailing 
sion key (RNl ©RN2). This is so because a one-time each packet with a 32 bit check sum field, which is part 
pad has been computed over each of RNl and RN2 of the packet data that gets encrypted. This will provide 
using the other as the one-time key. both integrity and privacy for the data packets, but no 
' If the connection attempt succeeds, mutual authenti- playback protection. Playback protection for data pack- 
cation has taken place and a session key has been ob- ets is not deemed to be important. It is likely that any 
tained. playback attempt will be rejected by higher layer proto- 

As illustrated, the message fields that are cross cols like TCP/TP4, etc. Since playbacks are possible in 

hatched in FIG. 3 are the parts that are encrypted using the normal (benign) datagram environment, an attacker 

either a private key (for digital signature purposes) or a caimot hope to achieve malicious results by injecting 

public key (to protect the session key components). playbacks of data packets. 

ItaHcs in the figure denote the fact that the itahcized , . 

fields are only part of the signature block and not the ^ CHANGE PROTOCOL OF THE PRESENT 

message itself. The signature on message 2 serves three INVENTION 

distinct purposes: i) to authenticate message #2 ii) to A Change Key message exchange can be initiated by 

serve as a challenge response to message #1 and iii) to either the base or the mobile 100. Base 105 initiates the 

authenticate message # 1 (by includmg the list of SKCSs key change as follows: 

in it). This has the result of minimizing the use of the 1. Base 105-*-Mobile 100 

public key cryptosystem, thereby optimizing the proto- Signed(Priv-3ase, {E(Pub— Mobile, New-RNl), 

col to run on platforms with limited computational jq E(Pub_Mobile, RNl)}) 

resources, yet the protocol of the present invention still 2. Mobile 100-^Base 105 

provides strong security gxiarantees. Signed(Priv_Mobile, {E(Pub_Base, New_RN2), 

The computationally expensive portion of public key E(Pub_Base, RN2)}) 

cryptosystems are typically the private key operations. If the Mobile 100 initiates the key change, the proce- 

Public key cryptosystems such as RSA (See RSA Data 35 dure is as follows: 

Security, Inc. PKCS #1-#10, June 1991) typically 1. MobOe lOO-^Base 105 

choose the keys so as to mmnnize the signature verifica- Signed(Priv— MobOe, {E(Pub_Base, New_RN2), 

tion process and public key encryption process. There- E(Pub— Base, RN2)}) 

fore, to assess the efficiency of the prcHocol, the total 2. Base 105-^Mobile 100 

number of private key operations arc counted. The 40 Signed(Priv_Base, {E (Pub-Mobile, New_RN 

mobile 100 performs two private key operations, the 1), E(Pub_Mobile RNl) }) 

first one to decrypt RNl and the second one to sign The value (New_RN20New_RNl) is used as the 

message #3. The base 105 also performs two private new key. The values RNl and RN2 are always derived 

key operations, the first one to sign message #2 and the from the last key exchange, which may be from the 

second one to decrypt RN2 from message #3. The total 45 initial connection setup or from the last key change 

computationally expensive (private key) operations thus message, whichever is more recent 

number only four in the present invention. No matter which unit (base or mobile) initiates the 

Using the teachings of the present invention, the key key change, RNl always refers to the portion of the key 

that is exchanged in the message key is really two differ* generated by the base 105 and RN2 always refers to the 

ent keys, one for each direction of data transfer. This 50 portion of the key generated by the mobile 100. A 

prevents keystream reuse, in case the cipher is operating change key message will serve to reinitialize the SKCS. 

in an additive stream mode. The protocol encoding Each side verifies the signatures on the messages and 

described at the end of this Specification identifies how . compares RNl and RN2 with its internally stored val- 

the two keys for each direction are differentiated. ues. If the signature does not verify or the RN1/RN2 

DATA PACKET values do not match with the internally stored ones, the 

key change message will be ignored. This will prevent 

A primary issue for data packets is maintaining de-, key change messages from being played back, because 
cryptability of data packets in the presence of packet the messages are sensitive to the history of the key 
losses. Data packets may get lost or arrive out of order^ change. If key change messages could be played back 
because of noise or reflections on the wireless link. In 60 without detection, this could result in mismatched keys 
accordance with the present invention, the solutions' on the two legitimate ends, thus allowing a simple de- 
depend on the shared key cipher and the mode its oper- nial of service type of attack. Such an attack is pre- 
ating in. For additive stream ciphers, in order to stay "in eluded by the key change messages of the types de- 
sync" with the pseudo-random streams, on each side a ' scribed above. 

6^it ''message id" field will be sent in the clear at the 6S The present invention prevents key change messages 

beginning of each packet. This "message id" field will from being played back, without resort to sequence 

contain the total number of bytes that have been previ- numbers. Sequence numbers can be tedious to operate 

ously sent This will allow correct operation with addi- with in protocol implementations, since the sequence 
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numbers would need to be remembered across pow^ 
downs and machine reboots. 

OPERATION WITH MULTIPLE CAs 

The present mvention was described above in terms 5 
of a single network wide CA. For a large network, a 
single CA cannot service all the network nodes. In such 
cases, a hierarchy of CAs is employed. Such CA hierar- 
chies are described in detail in CCITT X.509 and the 
PEM RFCs. When a CA hierarchy is employed, the 10 
protocol is modified as follows. Message #2 wiU not 
include only the certificate of the base 105 station. In- 
stead, message #2 will send a certificate path, which 
will allow the mobOe unit to verify the base certificate. 
The certificate path will be constructed by the base 15 
station to start from the CA that issued the mobile's 
certificate. Since the base is connected to the wired 
network, it has access to network databases (directory 
services) that allow the base to construct such a path. 
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-continued 



Message - 3:: = SEQUENCE { 
baseToMobiIeRN2 
mobaerroBaseRN2 
sigals 

messageSsig 



OCTET STRING. 
OCTET STRING. 
Algonthmklentifier. 
BIT STRING} 



Algorithmldentifer, Certificate and Certification 
Path are specified in X.509. CertificateRevocationList 
is defined in RFC 1422. The signal fields of messages #2 
and #3 identify the signature algorithm used to com- 
pute message2sig and message3sig respectively. This 
includes identification of both the hash algorithm and 
the public key cryptosystem. This is compatible in spirit 
with the SIGNED ASN.l MACRO OF X.509, except 
that the signature is not computed over fields that are 
entirely contained in the messages themselves. 



A set of standards from RSADSI, Inc., collectively 

The mobile 100 cannot be configured to know all possi- 20 known as Public Key Cryptography Standards (PKCS) 



25 



ble certificate paths and so it is required simply to send 
its own certificate. This allows the configuration of a 
mobile 100 to be simple, while still allowing the flexibil- 
ity of allowing multiple CAs in the form of a CA hierar- 
chy. 

Another modification that is necessitated by the in- 
clusion of multiple CAs is that a mobile 100 cannot be 
expected to have an up-to-<late copy of Certificate Re- 
vocation List (CRL) for each CA in the certificate path. 
CRLs are necessary to accommodate the possibility that 
the private key corresponding to a certified public key 
may be compromised. In such an eventuality, that cer- 
tificate needs to be hot-listed or revoked. A CRL is such 
a hot list, listing all the certificates that have been re- 
voked by a CA. The base also has the responsibility of 
supplying the CRL for each CA in the certificate path. 
CRLs are described in detail in RFC 1422. The new 
message #2 is thu^ 
Message #2. Base 10S->Mobile lOO {Cert-Path, List 
of CRLs, E(Pub_Mobile, RNl), Chosen SKCS, 
Sig(Priv Jase, {E(Pub_Mobile, RNl), Chosen 
SKCS, CHI, List of SKCSs})} 

PROTOCOL ENCODING 

In order to provide a detailed description of the en- 
coding of the protocol, we specify the messages in 
ASN.l (See, "CCITT Recommendation X.208 (1988), 
"Specification of Abstract Syntax Notation (ASN.l)"). 
The encoding is performed usmg the DER subset of the 
ASN.l BER (CCTTT Recommendation X.209 (1988), 
"Specification of Basic Encoding Rules for ASN.l)"), 
as specified m X.509 Section 8.7: 
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Message #1, 
Message - I:: =» SEQUENCE { 
mobileCert 
cballengeToBase 
listOfSKCS 

Message #2. 
Message - 2:: « SEQUENCE { 
baseCertpath 
litOfCRLs 

baseToMobilcRNl 
mobileToBaseRNl 
chosenSKCS 
sigalg 

message2sig 
Message #3. 



Certificate, 
OCTET STRING, 
SEQUENCE OF 
AlgoriUimldentifier} 



CertificationPath. 
SEQimNCE OF 
CertificateRevocatioaList, 
O CTET STRING. 
OCTET STIUNG, 
Algorithmldentificr, 
Algorithmldentifier. 
BIT STRING} 
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(See RSA Data Security, Inc. PKCS #1-#10, June 
1991), specify several digital signature and public key 
algorithms. Examples of these include MD2 with RSA 
encryption and the RSA pubUc key cryptosystem. 
These may be employed for the certificate and protocol 
related digital signatures and public key encryptions. 

PROOF OF THE PRESENT INVENTION 
PROTOCOL 

The security of the protocol may be proved using the 
Logic of Authentication developed by Burrows, Abadi 
and Needham (See M. Burrows, M. Abadi, R. Need- 
ham, "A Logic Authentication", DEC SRC Research 
Report #39, Feb. 22, 1990). The formalism as described 
has linutations in describing serverless protocols, such 
as the present invention. The limitation has to do with 
accepting the validity of a public key certificate. All 
that can be logically derived from a certificate is that 
the CA once said "Ko speaks for A". Nothing can be 
said about whether the CA still believes the certificate 
to be valid. In practice, this is handled by a Certificate 
Revocation List and validity periods on the certificate 
itself. This is a limitation because the only way of pro- 
moting once said to believes i the original formalism is 
by use of the fre^ess property of the statement. In a 
serverless protocol, such a fredmess guarantee cannot 
be provided, because the server is not necessarily avail- 
able at the time of communication. 

Having noted this problem, the certificate is assumed 
to be fresh unless there is a statement to the contrary. 
To analyze the protocol, the idealized version of the 
protocol is first derived. To do this, we dispense with 
elements that have no place in the formalism. This in- 
cludes all clear-text communication, as well as the nego- 
tiation of the shared key algorithm. Fust, the stripped 
down concrete protocol is provided, followed by its 
idealized version. (The same notation as used by Abadi, 
et al.) A is the mobile 100 and B is the base 105. CHI is 
Nfl. 



65 



Concrete Protocol: 



Message I: A • 



{^4 



I 

Kea 
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-continued -continued 



Message 3: J? {{JUV2}jci, 



Trifalirrri Protocol: 
10 



PROOF 



^ \ From message #2, assumptions b) and c), the mes- 

sage-meaning and jurisdiction rules and the assertion 
Message 2: that Certi^B is assumed fresh, we get. 

Message 3: a -^^ ( (/< ^ ) . OWDitt )_, >jtll**> J 

Proof Assumptions: ^ * t • >.t- • i x 

Applymg the message-meanmg rule, we get 



tL)A 



40 



Kca 

From assumption d) and the nonce-verification rule 

Applying the jurisdiction rule and assumption n) 
^^^^<Ml>j,^ -Resuhl 



From message #1, assumptions g) and h), the mes- 
sage-meaning and jurisdiction rules and the assertion 
g) |^"> CA that Cert_A is assumed fresh, we get 



^^)B^(ca)=^\^a) b^)^a 

, From message #3, we get 

\)B^§iRm) 55 



I 

Ka 



^ Applying the message-meaning rule we get 



^)ca)^\^a 

r^CA^^CA ' B)^A^[{A<Mi^B),iHm,^) 

* 65 



m)G4 



^ Applying the nonce-verification rule and assumption 

^\^^ i) 
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Applying the jurisdiction rule and assiimption o) 



10 



From Result — 1 and the conclusion above, we sum- 
marize the following two results, 



It follows that since, 



) 



15 



20 



25 



then from assumptions e) and j) and the two results 
above we get 



30 
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These are the goals of an authentication protocol. The 
Logic of Authentication formalism does not deal with 
issues such as forward secrecy, but this is an additional 
goal of the protocol of the present invention. Also, in 
the present invention, the use of synchronized clocks is 
avoided. Requiring synchronized clocks has many 
problems associated with it (See, W. Diffie, P.C.V. 
Oorschot, M. J. Wiener, "Authentication and Authenti- 
cated Key Exchanges", in "Designs, Codes and Cryp- 
tography", pages 107-125, Kluwer Academic Publish- 
ers, 1992). Using a challenge response mechanism 
avoids these problems. Assumption i) makes explicit the 
fact that part of the session key (RNl) is being used for 
authentication purposes, another desirable attribute of 
an authentication protocol. 

Assumptions n) and o) are unusual in that each side 
expresses a belief in the authority of the other side to 
produce an acceptable key component This is neces- 
sary in a sexverless protocol, because one or both of the 
parties are responsible for generating the session key. 
This is a reflection of the unstated requirement in the 
protocol of competence on both sides to pick keys that 
have the appropriate properties of randomness and 60 
unpredictability. 

CONCLUSION 

Accordingly, a system and method for privacy and 
authentication for wireless networks is disclosed. While 65 
the present invention has been described in conjunction 
with a few specific embodiments identified in FIGS. 
1-Sb, it will be apparent to those skilled in the art that 
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many alternatives, modifications and variations in light 
of the foregoing description are possible. 
We claim: 

1. An improved method for providing secure commu- 
nications between, a first data processing device and a 
second data processing device, comprising the steps of: 

(a) said first data processing device transmitting a first 
message inducting: a Mobile Certificate (Cert-^o- 
bile) including a mobile public key (Pub— Mobile), 
a chosen challenge value (CHI), and a list of sup- 
ported shared key algorithms (SKCS), to said sec- 
ond data processing device; 

(b) said second data processing device receiving said 
first message and verifying a first signature of a first 
certificate authority (CA), said second data pro- 
cessing device validating said received Cert-^o- 
bUe, and if said Cert_Mobile is vahd, said second 
data processing device transmitting a second mes- 
sage including: a Base Certificate (Cert— Base) in- 
cluding a base public key (Pub— Base), a second 
digital signature,. a random number (RNl), and an 
identifier of one of said SKCS chosen from said list 
of supported shared key algorithms, to said first 
data processing device; 

(c) said first data processing device receiving said 
second message and validating said CerUBase, and 
if said Cert Base is valid, said first data processing 
device validating said second signature of said Cer- 
t-3ase using said Pub— Base, such that if said sec- 
ond signature is valid, said first data processing 
device determining the value of RNl by decrypt- 
ing the value of E(Pub-^obile, RNl) using a pri- 
vate key of said first data processing device 
(Priv-Mobae); 

(d) said first data processing device generating a 
value RN2 and a first session key having the value 
(RN1®RN2), said first data processing device 
encrypting the value of RN2 using said base public 
key (Pub Rase), and sending a third message to 
said second data processing device including said 
encrypted RN2 and the value of E(Pub_Mobile, 
RNl) along with a digital signature corresponding 
to said first data processing device; 

(e) said second data processmg device receiving said 
third message and verifying said digital signature of 
said first data processing device using Pub—Mobile 
obtained firom said Cert-Mobile, and if said signa- 
ture of said first data processing device is verified, 
said second data processing device decryptmg the 
value of £(Pub— Base, KS2) using a private key of 
said second data processing device (Priv— Base), 
said second data processing device using said first 
session key having the value of (RN1©RN2); 

(f) said first and second data processmg devices trans- 
ferring data using encrypted data which is de- 
crypted using said first session key. 

2. The method as defined by claim 1 wherein said 
Cert— Mobile comprises the expression: 

Signed(Priv— CA, Certificate contents). 

3. The method as defined by claim 2 wherein said 
Certificate contents comprises: 

{Serial Number, Validity Period, Machine Name, 
Machine Public Key, CA name}. 

4. The method as defined by claim 3 wherein said 
MD is signed by said CA by encrypting said MD under 
said private key of said CA, s\ich that the content of said 
Cert— Mobile are authenticated 
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5. The method as defined by claim 4 wherein said 
CHI comprises a randomly generated number. 

6. The method as defined by claim 5 wherein said step 
of validating said received Cert-Mobile of step (b) 
includes the steps of: ^ 

said second data processing device independently 
computing said MD function on the contents of 
Cert—Mobil^ 

said second data processing device comparing said 
independently computed MD function with the 
decryption under said public key of said CA of said 
MD signed by said CA in Step (b) of claim 1, such 
that if said MDs match said Cert— Mobile is valid.. 

7. The method as defined by claim 6 wherein said 
RNl value is encrypted using said Pub— Mobile of said 
first data processing device. 

8. The method as defined by claim 7 wherein said 
second data processing device stores said RNl value, 
and includes said CHI value and said identifier of said 
chosen SKCS in messages between said second and said 
first data processing devices. 

9. The method as defined by claim 8 wherein said 
second message comprises the expression: 

{Cert-Base, E(Pub-Mobile, RNl). Chosen SKCS, 25 
Sig(Priv-Base,{E(Pub_Mobile, RNIX Chosen 
SKCS, CHI, List of SKCSs})}. 

10. The method as defined by claim 9 wherein said 
second digital signature is verified in Step (b) of claim 1 
by appending said second message to CHI and said hst 30 
of SKCSs. 

11. The method as defined by claim 10 wherein said 
value RN2 comprises a random number. 

12. The method as defined by claim 11 wherein said 
third message comprises the expression: 35 

{E(Pub_Base, RN2), Sig{Priv_Mobile, {E(- 
Pub-Base,RN2), E(Puh-MobUe, 

13. The method as defined by claim 12 wherein said 
CHI value comprises a 128 bit number. 

14. The method as defined by claim 12 further includ- ^ 
mg a key change method to define a New Key, compris- 
ing the steps of: 

(a) said second data processing device sending a forth 
message comprising: Signed(Priv-JBase, {£(- 
Pub-MobUe, New-RNl). E(Pub-MobUc. 
RNl)}); 

(b) said first data processing device receiving said 
forth message and send a fifth message to said sec- 
ond data processing device comprising: Signed(- 
Priv— Mobile, {E(Pub_Base, New— RN2), E(- 
Pubu-Base, RN2)}); 

wherein the value of RN20RN1 is used as the New 
Key. 

15. The method as defined by claim 12 further includ- 
ing a key change method to define a New Key, compris- 
ing the steps of: 

(a) said first data processing device sending a forth 
message to said second data processing device 
comprising the expression: Signed(Priv— Mobile, 
{E(Pub-Base, New-RN2). E(Pub-Base, RN2)}); 

(b) said second data processing device receiving said 
forth message and sending a fifth message to said 
first data processing device comprising the expres- 
sion: Signed(Priv-Base, {E(Pub_Mobile, Ne- 65 
w_RNl), E(Pub_Mobae. RNl)}); 

wherein the value of RN2 ©RNl is used as the New 
Key. 
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16. The method as defined by claim 1 further includ- 
ing a plurality of CAs, and wherein said second message 
is defined by the expression: 

{Cert-Path, List of CRLs, E(Pub_Mobile, RNl), 
Chosen SKCS, Sig(Priv-Base, {E(Pub_Mobile, 
RNl). Chosen SKCS, CHI, List of SKCSs})}and 
wherein: 

CRL comprises a certificate revocation list for each 
of said CAs, 

17. In a network having a first data processing device 
in communication with a second data processing de- 
vice, an ^paratus for providing a secure data transfer 
between said first data processing device and said sec- 
ond data processing device, comprising: 

a first message generation and transmission/receiving 
circuit coupled to said first data processing device 
for transmitting^ first message including: a Mobile 
Certificate (Cert— Mobile) having a mobile public 
key (Pubu^obile), a chosen challenge value 
(CHI), and a list of supported shared key algo- 
rithms (SKCS), to said second data processing 
device 

second message generation and transmission/receiv- 
ing circuit coupled to said second data processing 
device for receiving said first message, said second 
data processing device validating said received 
Cert— Mobile, and if said Cert— Mobile is valid, said 
second data processing device transmitting a sec- 
ond message including: a Base Certificate (Cert 

Base) including a base public key (Pub— Base), a 
second digital signature, a random number (RNl), 
and an identifier of one of said SKCS chosen from 
said list of supported shared key algorithms, to said 
first data processing device 

said first data processing device receiving said second 
message using said first message and transmission/- 
receiving means and validating said Cert— Base, 
and if said Cert— Base is valid, said first data pro- 
cessing device validating said second signature of 
said message using said Pub— Base, such that if said 
second signature is valid, said first data processing 
device determines the value of RNl by decrypting 
the value of E(Pub_Mobile, RNl) using a private 
key of said first data processing device (Priv— Mo- 
bile); 

said first data processing device generating a value 
RN2 and a first session key having the value 
(RN10RN2), said first data processing device 
encrypting the value of RN2 using said base public 
key (Pub— Base), and sending a third message to 
said second data processing device including said 
encrypted RN2 and the value of E(Pub-Mobile, 
RNl) along with a digital signature corresponding 
to said first data processing device; 

said second data processing device receiving said 
third message using said second message and trans- 
mission/receiving means and verifying said digital 
signature of said first data processing device using 
Pub— Mobile obtained fi-om said Cert— Mobile, and 
if said signature of said first data processing device 
is verified, said second data processing device de- 
crypting ^e value of E(Pub— Base, RN2) using a 
private key of said second data processing device 
(Priv— Base), said second data processing device 
using said first session key having the value of 
(RN1©RN2); 
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said first and second data processing devices transfer- 
ring data using encrypted data which is decrypted 
using said first session key. 

18. The apparatus as defined by claim 17 wherein said 
Cert— Mobile comprises the expression: 

Signed(Priv_CA, Certificate contents). 

19. The apparatus as defined by claim 18 wherein said 
Certificate contents comprises: 

{Serial Nmnber, Validity Period, Machine Name, 
Machine Public Key, CA name}. 

20. The apparatus as defined by claim 19 wherein said 
MD is ^gned by said CA by encrypting said MD under 
said private key of said CA, such that the content of said 
CertlMobile are authenticated. ]5 

21. The apparatus as defined by claim 20 wherein said 
CHI comprises a randomly generated number. 

22. The apparatus as defhied by claim 21 wherein said 
step of validating said received Cert_Mobile is deter- 
mined by: 20 

said second data processing device independently 
computing said MD function on the contents of 
Cert-Mobile; 

said second data processing device comparing said 
independently computed MD function with the 25 
decryption under said public key of said CA of said 
MD signed by said CA, such that if said MDs 
match said Cert— Mobile is valid. 

23. The apparatus as defmed by claim 22 wherein said 
RNl value is encrypted using said Pub_Mobile of said 
first data processing device. 

24. The apparatus as defined by claim 23 wherein said 
second data processing device stores said RNl value, 
and includes said CHI value and said identifier of said 
chosen SKCS in messages between said second and said 
first data processing devices. 

25. The apparatus as defined by claim 24 wherein said 
second message comprises the expression: 

{Cert-Base, E(Pub_Mobile, RNl), Chosen SKCS, 40 
Sig(Priv— Base,{E(Pub— MobUe, RNl), Chosen 
SKCS, CHI, List of SKCSs))}. 

26. The apparatus as defined by claim 25 wherein said 
second digital signature is verified by appending said 
second message to CHI and said list SKCSs. 45 

27. The apparatus as defined by claim 26 wherein said 
value RN2 comprises a random number. 
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28. The apparatus as defined by claim 27 wherein said 
third message comprises the expression: . 

{E(Pub_ABe. Rn21 Sig{Priv-Mobile, {E(- 
Pub_Base,RN2), E(Pub_Mobile, 

29. The apparatus as defined by claim 28 wherein said 
CHI value comprises a 128 bit number. 

30. The apparatus as defined by claim 29 wherein a 
New Key may be defined: 

said second data processmg device using said second 
message and transmission/receiving means sends a 
forth message comprising: Signed(Priv— Base, {£(- 
Pub^Mobile. New_RNl). E(Pub-Mobile, 
RNl)}) to said first data processmg device 

said first data processing device using said first mes- 
sage and transmission/receiving means receives 
said forth message and sends a fifth message to said 
second data processing device comprising: Sig- 
ned(Priv_Mobile, {E(Pub— Base, New_RN2), 
E(Pub-Jaase, RN2)}); 

wherein the value of RN2®RNi is used as the New 
Key. . 

31. The apparatus as defined by claim 30 wherem a 
New Key may be defined: 

said first data processing device using said first mes- 
sage and transmission/receiving means sends a 
forth message to said second data processing de- 
vice comprising the expresaon: Signed(Priv-JM[o- 
bile, {E(Pub_Base, New-_RN2), E(Pub-Base, 
RN2)}>, 

said second data processing device receiving said 
forth message using said second message and trans- 
mission/receiving means and sends a fifth message 
to said first data processing device comprising the 
expression: Signed(Priv— Base, {E(Pub— Mobile, 
New-JWl), E(Pub_MobUe, RNl)}); 

wherein the vdue of RN2 if) RNl is used as the New 
Key. 

32. The apparatus as defined by claim 17 further in- 
cluding a plurality of CAs, and wherein said second 
message is defined by the expression: 

{Cert:»Path, List of CRLs, E(Pub_Mobile, RNl), 
Chosen SKCS, Sig(Priv-JBase, {E(Pub-Mobile, 
RNl), Chosen SKCS, CHI, List of SKCSs})} 
and wherein: 

CRL comprises a certificate revocation list for each 
of said CAs. 
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